Hardware-based functional verification systems, including hardware emulation systems and simulation acceleration systems, utilize interconnected programmable logic chips or interconnected processor chips. Examples of systems using programmable logic devices are disclosed in, for example, U.S. Pat. No. 6,009,256 entitled “Simulation/Emulation System and Method,” U.S. Pat. No. 5,109,353 entitled “Apparatus for emulation of electronic hardware system,” U.S. Pat. No. 5,036,473 entitled “Method of using electronically reconfigurable logic circuits,” U.S. Pat. No. 5,475,830 entitled “Structure and method for providing a reconfigurable emulation circuit without hold time violations,” and U.S. Pat. No. 5,960,191 entitled “Emulation system with time-multiplexed interconnect.” U.S. Pat. Nos. 6,009,256, 5,109,353, 5,036,473, 5,475,830, and 5,960,191 are incorporated herein by reference. Examples of hardware logic emulation systems using processor chips are disclosed in, for example, U.S. Pat. No. 6,618,698 “Clustered processors in an emulation engine,” U.S. Pat. No. 5,551,013 entitled “Multiprocessor for hardware emulation,” U.S. Pat. No. 6,035,117 entitled “Tightly coupled emulation processors,” U.S. Pat. No. 6,051,030 entitled “Emulation module having planar array organization,” and U.S. Pat. No. 7,739,093 entitled “Method of visualization in processor based emulation system.” U.S. Pat. Nos. 6,618,698, 5,551,013, 6,035,117, 6,051,030, and 7,739,093 are incorporated herein by reference.
Functional verification systems help to shorten the time it takes to design customized application specific integrated circuits (ASICs) by allowing designers to emulate the functionality of the ASIC before a production run has begun. Functional verification systems help to ensure ASICs are designed correctly the first time, before a final product is produced.
Emulators may be either processor-based or field programmable gate array (FPGA) based emulation systems. Processor-based emulation systems comprise one or more emulation boards that include one or more processor-based emulation chips used to implement at least a portion of a hardware design. FPGA-based emulation systems comprise emulation boards comprising FPGA—based emulation chips used to implement at least a portion of a hardware design. The emulation boards are divided into domains that can implement a number of logic gates. For example, each emulation board may comprise eight domains with each domain capable of implementing on the order of a million logic gates. Hardware designs may be allocated amongst the domains of the emulation boards. This allocation allows multiple workstations, each trying to emulate a different hardware design, to utilize the processor-based emulation system simultaneously.
Processor-based emulation system may fail for a variety of reasons. One cause of failure is that there is a problem with interconnections of the processor-based emulation system. Interconnections connect emulation chips of an emulation board, emulation boards to a backplane, and backplanes to system chassis, and chassis to other chassis. These interconnections may comprise copper wires, copper backplanes, optical fibers, or other suitable connections.
When an interconnection failure occurs, the emulation board may need to be replaced. The interconnection failure interferes with the functional verification process because hardware designs cannot be properly implemented in the processor-based emulation system. Further, if a hardware design is being implemented in the processor-based emulation system, an interconnection failure may result in errors or “bugs” being introduced into the implementation process that are attributable to the interconnection failure rather than to a fault in the hardware design.
When replacing an emulation board, interconnections coupled to the emulation board should be tested to ensure the interconnections are working properly. One way of testing the interconnections is to implement test logic, which if implemented correctly, outputs a specific pattern or signal. The test logic is implemented on the domains coupled to the interconnections to be tested. An origin emulation chip transmits signals generated according to the test logic over an interconnection to a destination emulation chip. The destination emulation chip then checks the signals to determine whether the correct signal was received. In this way, the interconnections between the origin and destination emulation chips may be tested. Thus, the interconnection testing process involves at least two tested domains at a time, and may involve domains on the same emulation board or different emulation boards.
Unfortunately, the tested domains cannot run a hardware design and the test logic at the same time. In fact, the tested domains must be taken “offline” and may have to run the test logic for several hours, during which time the domain cannot run hardware designs. This can be especially problematic when an emulation board must be replaced because the domains on the emulation board should be tested to determine whether the interconnections are working properly. This may require taking the entire processor-based emulation system offline since the emulation board may be coupled to all the other emulation boards, requiring all emulation boards to be offline while testing the interconnections.
Some systems allow hardware designs to be allocated to domains that are not currently being tested in order to prevent full processor-based emulation system shutdown. To test interconnections of the replaced emulation board, all emulation boards may eventually need to be tested. After the interconnections between the replaced emulation board and a first emulation board have been tested, the interconnections between the replaced emulation board and a second emulation board may be tested. This testing process should continue until all interconnections of the replaced emulation board have been tested.
While the interconnections are tested, hardware designs may need to be re-located, e.g., executed in different groups of emulation processor chips. In the preceding example, a hardware design running on the second emulation board would be transferred to the first emulation board before testing the interconnections between the replaced emulation board and the second emulation board. This process would continue for all tested emulation boards. In this way, different emulation boards of the processor-based emulation system may be taken offline, while allowing the processor-based emulation system to allocate hardware designs to emulation boards that are online.
This re-location process presents its own problems. First, the re-location process is disruptive. The re-location process requires loading the hardware design onto different emulation chips which takes time, perhaps several hours. To re-locate a design, the state of the hardware design implementation must also be saved and transferred to the new emulation chip in the saved state. Thus, some delay occurs while waiting for the verification process to reach a state that can be saved. Second, the re-location process does not work with domains that are communicating with external targets. The state of the external target cannot be stopped or saved while the domain's hardware design is re-located. Thus, domains communicating with external targets may not be re-located. Third, not all hardware designs may be re-located. A hardware design programmed onto one or more emulation boards will comprise a “hierarchy,” or shape. For example, a hardware design may, for example, be implemented on four domains, where the domains on the same emulation board comprise an “L” shape. The hardware design may only be re-located to domains comprising the same hierarchy—in this case an “L” shape—which may not exist when other domains of the processor-based emulation system are in use.
Although currently employed methods and systems for interconnection diagnostics are useful to a degree, there still exists a need for systems that enable concurrent hardware design verification and interconnection diagnostics. Thus, for at least these reasons there is a need for an improved system and method for concurrent interconnection diagnostics.